Summary

On Windows, an external ACP agent runtime (e.g. the Claude Code adapter) pops a fresh, lingering console window for every agent subprocess. This makes buzz-acp on Windows visually broken when the agent isn't the bundled buzz-agent.

Root cause

The desktop already spawns the harness with CREATE_NO_WINDOW — desktop/src-tauri/src/managed_agents/runtime.rs sets it, with a comment noting "Without this a bare terminal pops for buzz-acp.exe and lingers". So buzz-acp runs with no console of its own.

But AcpClient::spawn (crates/buzz-acp/src/acp.rs) launches the agent subprocess without that flag (only #[cfg(unix)] process_group(0) is set). Because the parent has no console to share, Windows allocates a new visible console for each console-subsystem agent child — the claude-agent-acp / goose cmd shim, node, claude.exe. External adapters (Claude Code runtime) hit this; the GUI-subsystem bundled buzz-agent does not, which is why it only shows up with external runtimes.

Fix

Mirror the desktop's suppression at the harness spawn: set CREATE_NO_WINDOW on Windows in AcpClient::spawn, alongside the existing #[cfg(unix)] process_group(0). tokio::process::Command::creation_flags is inherent on Windows. stdio pipes are unaffected.

#[cfg(windows)]
{
    const CREATE_NO_WINDOW: u32 = 0x0800_0000;
    cmd.creation_flags(CREATE_NO_WINDOW);
}

Repro

Windows, Buzz 0.4.22, deploy an agent using the Claude Code runtime → a console window pops (per agent child) and lingers. With buzz-agent (GUI subsystem) it does not.

Testing

Change is a 6-line #[cfg(windows)] addition mirroring code already present in the desktop crate. Full disclosure: I could not run a local Windows build to exercise it end-to-end (my machine has no MSVC linker installed), so I'm relying on the review + CI here rather than claiming a local run. Happy to adjust placement/style.